Address Resolution Protocol

The Address Resolution Protocol (ARP) is a computer networking protocol for determining a network host's link layer or hardware address when only its Internet Layer (IP) or Network Layer address is known. This function is critical in local area networking as well as for routing internetworking traffic across gateways (routers) based on IP addresses when the next-hop router must be determined. ARP was defined by RFC 826 in 1982.[1] It is Internet Standard STD 37.

ARP has been implemented in many types of networks, such as Internet Protocol (IP) network, CHAOS, DECNET, Xerox PARC Universal Packet, Token Ring, FDDI, IEEE 802.11 and other LAN technologies, as well as the modern high capacity networks, such as Asynchronous Transfer Mode (ATM). Due to the overwhelming prevalence of IPv4 and Ethernet in general networking, ARP is most frequently used to translate IPv4 addresses (OSI Layer 3) into Ethernet MAC addresses (OSI Layer 2).

In the next generation Internet Protocol, IPv6, ARP's functionality is provided by the Neighbor Discovery Protocol (NDP).

Internet Protocol Suite
Application Layer

BGP · DHCP · DNS · FTP · HTTP · IMAP · IRC · LDAP · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · SIP · SMTP · SNMP · SSH · Telnet · TLS/SSL · XMPP ·

(more)
Transport Layer

TCP · UDP · DCCP · SCTP · RSVP · ECN ·

(more)
Internet Layer

IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec ·

(more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)

Contents

Overview and IPv4-plus-Ethernet example

Consider a LAN where machines using IPv4 over Ethernet wish to communicate. A sender wishes to send a message to some other machine on the LAN and knows a destination IPv4 address. The destination IPv4 address is hopefully associated with some appropriate network interface belonging to the recipient machine, and is present on the LAN. But in order for communication to succeed, the sending machine first needs to discover the ethernet MAC address of the intended recipient network interface. This requirement comes about because Ethernet hardware does not (necessarily) understand IPv4 protocols or IPv4 addresses in the sense that Ethernet hardware 'listens out for' relevant Ethernet MAC addresses but does not 'listen out for' IPv4 addresses. (An impractical alternative would be to have all units listen to every Ethernet packet and inspect the contents for relevant IPv4 addresses, discarding the packets that are intended for other devices, but this would be very inefficient.) So before sending an IPv4 packet, the sender sends a broadcast message onto the LAN using ARP in order to discover the Ethernet MAC address of some interface that is listening for that desired target IPv4 address. Some appropriate unit replies that it has a network interface with a certain MAC address that is associated with the IPv4 address in question. The original would-be sender now has the information needed and can go ahead and send its IPv4 packet to the destination inserting it into an Ethernet frame with the correct destination MAC address for the appropriate recipient. The sender's operating system also stores the newly discovered MAC address in a table ('caches' the result). This table of mappings from IPv4 addresses to MAC addresses is retained and consulted again and again, so the ARP discovery procedure only has to be performed one time, when a packet is sent to a 'new' destination IPv4 address. When a host goes down on a network, there is no message sent to inform the other hosts. They will continue to send messages to that MAC address and because Ethernet doesn't have guaranteed delivery, they will have no way of knowing that the address associated with that host is no longer correct. A timer is set when information is entered in to the ARP cache and it will be discarded when the time is up to prevent the storing of invalid information. A new ARP request will be sent to the stored MAC address to verify that it is in fact still connected.

Operating scope

The Address Resolution Protocol is a low level request and answer protocol that is communicated on the media access level of the underlying network. For Ethernet systems, an ARP message is the payload of Ethernet packets. ARP therefore operates only across the local link that a host is connected to.

Within the framework of the Internet Protocol Suite, this characteristic makes ARP a Link Layer protocol.[2]

ARP is also very often discussed in terms of the Open Systems Interconnect (OSI) networking model, because that model addresses hardware-to-software interfaces more explicitly and is preferred by some equipment manufacturers. However, ARP was not developed based on the design principles and strict encapsulation hierarchy of this model and, therefore, such discussions create a number of conflicts as to the exact operating layer within this model. Most often ARP is placed into the Data Link Layer (Layer 2), but since it requires the definitions of network addresses of the Network Layer, it is not unusual to find it referenced at that layer.

An example of use in OSI networking, is ATMARP, used to resolve Asynchronous Transfer Mode (ATM) NSAP addresses in IP over ATM deployments.

Packet structure

The Address Resolution Protocol uses a simple message format that contains one address resolution request or response. The size of the ARP message depends on the upper layer and lower layer address sizes, which are given by the type of networking protocol (usually IPv4) in use and the type of hardware or virtual link layer that the upper layer protocol is running on. The message header specifies these types, as well as the size of addresses of each. The message header is completed with the operation code for request (1) and reply (2). The payload of the packet consists of four addresses, the hardware and protocol address of the sender and receiver hosts.

The principal packet structure of ARP packets is shown in the following table which illustrates the case of IPv4 networks running on Ethernet. In this scenario, the packet has 48-bit fields for the sender hardware address (SHA) and target hardware address (THA), and 32-bit fields for the corresponding sender and target protocol addresses (SPA and TPA). Thus, the ARP packet size in this case is 28 bytes.

Internet Protocol (IPv4) over Ethernet ARP packet
bit offset 0 – 7 8 – 15
0 Hardware type (HTYPE)
16 Protocol type (PTYPE)
32 Hardware address length (HLEN) Protocol address length (PLEN)
48 Operation (OPER)
64 Sender hardware address (SHA) (first 16 bits)
80 (next 16 bits)
96 (last 16 bits)
112 Sender protocol address (SPA) (first 16 bits)
128 (last 16 bits)
144 Target hardware address (THA) (first 16 bits)
160 (next 16 bits)
176 (last 16 bits)
192 Target protocol address (TPA) (first 16 bits)
208 (last 16 bits)
Hardware type (HTYPE)
This field specifies the Link Layer protocol type. Example: Ethernet is 1.
Protocol type (PTYPE)
This field specifies the upper layer protocol for which the ARP request is intended. For IPv4, this has the value 0x0800. The permitted PTYPE values share a numbering space with those for Ethertype.[3][4][5]
Hardware length (HLEN)
Length (in octets) of a hardware address. Ethernet addresses size is 6.
Protocol length (PLEN)
Length (in octets) of addresses used in the upper layer protocol. (The upper layer protocol specified in PTYPE.) IPv4 address size is 4.
Operation 
Specifies the operation that the sender is performing: 1 for request, 2 for reply.
Sender hardware address (SHA)
Hardware (MAC) address of the sender.
Sender protocol address (SPA)
Upper layer protocol address of the sender.
Target hardware address (THA)
Hardware address of the intended receiver. This field is ignored in requests.
Target protocol address (TPA)
Upper layer protocol address of the intended receiver.

ARP protocol parameter values have been standardized and are maintained by IANA.[6]

ARP probe

An ARP probe is an ARP request constructed with an all-zero sender IP address. The term is used in the IPv4 Address Conflict Detection specification (RFC 5227). Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means), a host implementing this specification must test to see if the address is already in use, by broadcasting ARP probe packets.

ARP announcements

ARP may also be used as a simple announcement protocol. This is useful for updating other host's mapping of a hardware address when the sender's IP address or MAC address has changed. Such an announcement, also called a gratuitous ARP message, is usually broadcast as an ARP request containing the sender's protocol address (SPA) in the target field (TPA=SPA), with the target hardware address (THA) set to zero. An alternative is to broadcast an ARP reply with the sender's hardware and protocol addresses (SHA and SPA) duplicated in the target fields (TPA=SPA, THA=SHA).

An ARP announcement is not intended to solicit a reply; instead it updates any cached entries in the ARP tables of other hosts that receive the packet. The operation code may indicate a request or a reply because the ARP standard specifies that the opcode is only processed after the ARP table has been updated from the address fields.[7][8][9]

Many operating systems perform gratuitous ARP during startup. That helps to resolve problems which would otherwise occur if, for example, a network card was recently changed (changing the IP-address-to-MAC-address mapping) and other hosts still have the old mapping in their ARP caches.

Gratuitous ARP is also used by some interface drivers to effect load balancing for incoming traffic. In a team of network cards, it is used to announce a different MAC address within the team that should receive incoming packets.

ARP announcements can be used to defend link-local IP addresses in the Zeroconf protocol (RFC 3927), and for IP address takeover within high-availability clusters.

ARP mediation

ARP mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on multiple connected circuits, e.g., ATM on one end and Ethernet on the others.

Inverse ARP and Reverse ARP

The Inverse Address Resolution Protocol (Inverse ARP or InARP), is a protocol used for obtaining Network Layer addresses (e.g., IP addresses) of other nodes from Data Link Layer (Layer 2) addresses. It is primarily used in Frame Relay (DLCI) and ATM networks, in which Layer 2 addresses of virtual circuits are sometimes obtained from Layer 2 signaling, and the corresponding Layer 3 addresses must be available before these virtual circuits can be used.

As ARP translates Layer 3 addresses to Layer 2 addresses, InARP may be described as its inverse. In addition, InARP is actually implemented as a protocol extension to ARP. It uses the same packet format from ARP; but has different operation codes.

Reverse Address Resolution Protocol (Reverse ARP or RARP), like InARP, also translates Layer 2 addresses to Layer 3 addresses. However, while in InARP the requesting station is querying the Layer 3 address of another node, RARP is used to obtain the Layer 3 address of the requesting station itself for address configuration purposes. RARP is now obsolete. It was replaced by BOOTP, which was later superseded by the Dynamic Host Configuration Protocol (DHCP).

See also

References

  1. David C. Plummer (1982-11). "RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware". Internet Engineering Task Force, Network Working Group. http://tools.ietf.org/html/rfc826. 
  2. RFC 1122, Requirements for Internet Hosts -- Communication Layers, R. Braden (Ed.), Internet Engineering Task Force (October 1989)
  3. IANA ARP - "Protocol Type"
  4. IANA - Ethertype values
  5. RFC 5342
  6. "IANA ARP parameter assignments". IANA. 2009-04-24. http://www.iana.org/assignments/arp-parameters/. 
  7. Gratuitous ARP in DHCP vs. IPv4 ACD Draft
  8. RFC 2002 Section 4.6
  9. RFC 2131 DHCP – Last lines of Section 4.4.1

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

External links